REMARKS 

Claims 1 and 3-48 are pending in the present application. Claims 1 and 3-48 
are rejected. 

Rejection of Claims under 35 U.S.C. § 112, first paragraph 

Claims 1 and 3-48 are rejected under 35 U.S.C. § 1 12, first paragraph, as 

failing to comply with the written description requirement. 1 The Examiner asserts 

that the claims contain subject matter which was not described in the specification in 

such a way as to reasonably convey to one skilled in the relevant art that the 

inventors, at the time the application was filed, had possession of the claimed 

invention. Specifically, the Examiner asserts: 

There is recited in the independent claims "application-specific 
value" and "general value." These separate recitations are 
further recited as stored on separate "electronic applications." A 
lack of written description appears to be present because there is 
further recited in the independent claims an exchangeability and 
compatibility which would not allow one with ordinary skill in 
the art at the time the application was filed to distinguish one 
type of value over the other , and therefore be able to practice the 
invention as claimed. 

(Emphasis added). The rejection under § 1 12, first paragraph, is respectfully 
traversed. It appears essentially that the Examiner is stating that one skilled in the art 
would not be able to distinguish "application-specific value" and "general value" as 
recited in the claims because the claims also recite that the "application-specific 
value" and "general value" are each exchangeable between each other in the 
transaction application and that the "application-specific value" and the "general 
value" are each compatible within the system for performing the financial 
transaction.. However, the disclosure specifically defines these terms and provides 
examples of each and what is meant by "exchangeable" and "compatible." For 



1 The Office Action refers to claims 1-48; however, only claims 1 and 3-48 were pending at the time of the 
Office Action. 
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example, on page 7, lines 19-29 of the disclosure, the following definitions are 



provided: 

The term "general value" comprises value that is generally 
equivalent to cash in that the general value is readily accepted in 
a plurality of financial transactions. The term "application- 
specific value" comprises value that has limited acceptance, 
typically only for transactions associated with a specific 
application loaded onto the smart card. General value may be 
accessed by a specific application program and converted into 
application-specific value. Similarly, application-specific value 
may be able to be converted to general value. Alternatively, 
certain applications may limit or prohibit the conversion of their 
associated application-specific value to general value, such as 
entitlement [e.g., Welfare] program applications. Thus, while 
general value and application-specific value may be readily 
exchanged, the specific application program may provide 
specific rules governing the limits of the exchange. 

Further, on page 12, lines 9 and 20, the following definitions are provided: 
"Open purse application 28 is an application that stores general value ..." and "closed 
purse application 30 is an application that stores application-specific value. . . ." The 
disclosure also provides several examples involving exchangeability and 
compatibility, such as the following found in pages 17-20 of the disclosure: 

In operation, referring to Fig. 3, a typical value exchange 
transaction utilizing system 10 and smart card 12 may comprise 
performing a financial transaction at a merchant, over the 
Internet, at a local terminal or with another cardholder utilizing 
a RWD [Reader - Writer Device] (block 100). A 
communication channel must be established between smart card 
12 and the corresponding device (block 102). To establish the 
communication channel, the cardholder engages contact 
interface 14 into contact RWD 18 (blocks 104 and 106) or 
places contactless interface 16 in proximity of contactless RWD 
20 (blocks 108 and 110). A bi-directional communication then 
proceeds between card 12 and the respective RWD 18 or 20 that 
authenticates and verifies both the card the respective device 
(block 1 12). At this point, the cardholder may indicate the 
amount of value involved in the financial transaction, such as if 
the cardholder is loading value onto the card or if a card-to-card 
value exchange is being performed (block 1 14). Alternatively, 
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the cardholder may confirm the amount of value involved in the 
transaction, such as if utilizing card 12 in a merchant or Internet 
transaction. Similarly, this part of the transaction process may 
be implied, such as in transportation-related applications where 
a toll or fare may be charged depending upon distance traveled, 
time of day, customer status (i.e. senior citizen discount, 
preferred traveler), etc. Next, a choice may be made to utilize 
general value 32 from open purse application 28 or application- 
specific value 34 from closed purse application 30 (blocks 1 16 
and 118). Again, this choice may be predetermined, depending 
on the application with which smart card 12 is interacting. 

For example, in utilizing smart card 12 in a subway, the 
interacting RWD [Reader Writer Device] at an entry gate may 
automatically initiate a transportation application, such as MTA 
74, and hence initially look to use application-specific value 34, 
such as transit value 38. In contrast, when inserting smart card 
12 into a multi-functional terminal device having contact 
interface 14, the cardholder may be given a choice by the 
application program within the terminal device as to which type 
of value should be utilized. 

In either case, system 10 and the application program 
utilized inquire about the availability of sufficient value in the 
chosen application (block 120). If sufficient value exists, then 
the transaction is executed and the value exchange is performed 
and the transaction ends (blocks 122 and 124). If sufficient 
value does not exist, then the application may permit value from 
another closed or open purse application to be utilized (block 
126). This option may be application-specific as some forms of 
value may not be convertible, or may have a limited ability to be 
converted. For example, application-specific value 34 stored in 
a closed purse application 30 such as for entitlement programs, 
like a welfare program, may be restricted so that the value can 
only be used for transactions utilizing the closed purse 
application. If another application is permitted to be utilized, 
then the open or closed purse application may be chosen 
automatically, based on a pre-designation, or the cardholder 
may indicate which application to use (block 128). The value 
from the selected application may then be directly utilized to 
execute and end the transaction (blocks 130, 122 and 124), or it 
may be converted to value to be stored in the initial application 
and then utilized to execute and end the transaction (blocks 132, 
122 and 124). Alternatively, if another closed or open purse 
application is not chosen or permitted to be utilized, another 
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option may be to perform the auto-load function, as described 
above (block 134). If the auto-load is permitted and/or chosen, 
then value is added to the initial application and the transaction 
is executed and ended (blocks 132, 122 and 124). If the auto- 
load is not permitted and/or not chosen, then the transaction is 
ended (block 124). Thus, system 10 provides a simple, 
convenient and fast value exchange transaction utilizing dual 
interface smart card 12. 

*** 

Another advantageous feature of the present invention is 
the integration of open purse application 28 and closed purse 
application 30 into a single system. As mentioned above, this is 
accomplished by structuring closed purse application 30 to be 
compatible with open purse application 28. Compatibility is 
enabled by structuring the data and transaction information for a 
particular closed purse application 30 in a format compatible 
with the data and transaction information utilized by the 
particular open purse application 28 being utilized. An 
identification number associated with the card is preferably used 
to properly direct the closed purse application transaction 
information through the established back end computer systems 
22 utilized by the particular open purse system application 28. . . 

Rejection of Claims under 35 U.S.C. § 112, second paragraph 

Claims 1 and 3-48 are rejected under 35 U.S.C. § 1 12, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. Specifically, the Examiner asserts, 
"There is recited in the independent claims 6 application- specific value' and 'general 
value.' The meets and bounds are not clear for each type of value so that the 
recitations are vague and indefinite, especially since there is also claimed an 
exchangeability and compatibility between the two values." 

The rejections under § 1 12, second paragraph, is respectfully traversed for the 
same reasons provided above in addressing the § 1 12, first paragraph rejection. 



Rejection of Claims 1, 3-35, 37-42, and 44-48 under 35 U.S.C. S 103(a) 

Claims 1, 3-35, 37-42, and 44-48 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Carlisle et al. (U.S. 5,649,1 18), in view of Derksen (U.S. 
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5 5 478 5 993) and Gungl et al. (U.S. Pat. No. 5,912,453), and in further view of 
Electronic Payment Systems. 

The Examiner incorporated arguments found in the Final Office Action dated 
November 4, 2003. In view of the § 112 remarks presented above, the principal 
arguments presented in the Appeal Brief dated October 4, 2004 continue to be 
applicable and are presented below. 

Regarding independent claims 1,18, 25, 37, and 45, the Examiner considers 
that Carlisle teaches each and every claimed element, except: (a) application-specific 
value stored in the first application on the smart card, in addition to the general value 
stored in the second application on the smart card, that are both compatible within the 
system for performing a transaction, which the Examiner considers to be inherent in 
the claimed transaction system because it performs transactions; (b) general value that 
is stored in a second electronic application on the smart card, in addition to the 
application-specific value stored in the first electronic application on the smart card, 
which the Examiner considers to be taught by Derksen and Gungl; (c) exchanging a 
transaction amount of value that is at least a portion of the application-specific value 
or the general value between the smart card and the corresponding device, which the 
Examiner considers to be taught by Derksen and Gungl; and (d) storing the 
application-specific value and the general value on the smart card which are each 
exchangeable with one another in a transaction, which the Examiner considers to be 
taught by Derksen, Gungl, and Electronic Payment Systems. 

Carlisle discloses a smart card storing multiple accounts, such as Visa, 
MasterCard, Discover, ATM, food stamps, welfare, and unemployment accounts, and 
a look-up table that identifies the particular purchases that can be charged to a 
particular one of the accounts (e.g., non-food items cannot be charged to the food 
stamp account). As bar-coded items are scanned at a merchant POS terminal, the 
POS terminal refers to the look-up table to see which account to charge for each 
purchase. If the table indicates that a particular purchase can be charged to more than 
one account, the terminal charges a particular account or accounts according to a 
priority algorithm, or if the table does not provide an account for a particular 
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purchase, the terminal again charges a particular account or accounts according to a 
priority algorithm, or manually via a keyboard selection. See , e.g., Carlisle, Col. 1, 
line-Col. 2, line 67; and Col. 22, line 31 -Col. 24, line 18. 

As already noted, the terms "general value" and "application-specific value", 
as recited in each of independent claims 1,18, 27, 37, and 45, are defined terms 
meaning, respectively, value that is generally equivalent to cash in that the general 
value is readily accepted in a plurality of financial transactions and value that has 
limited acceptance, typically only for transactions associated with a specific 
application program and converted into application-specific value. As conceded by 
the Examiner, Carlisle neither teaches nor suggests general value that is stored in a 
second electronic application on the smart card, in addition to the application-specific 
value stored in the first electronic application on the smart card, as recited in claims 1, 
18, 27, 37, and 45. 

Moreover, Carlisle teaches away from having both a first application with 
application-specific value and a second application with general value on the smart 
card, as recited in claims 1,18, 27, 37, and 45. As noted, Carlisle discloses multiple 
applications 1 109, 1110, . . ., 1111 having multiple accounts A, B, . . ., n and those 
accounts may be implemented by application-specific values such as Visa, 
MasterCard, Discover, ATM networks, food stamp programs, etc. See , e.g., Carlisle, 
Col. 2, lines 21-30; Col. 19, line 35-Col. 20. line 23. The smart card of Carlisle et al. 
is equipped with "smart card memory for storing a plurality of data files." See , e.g., 
Carlisle, Col. 2, lines 21-22. Associated with each data file is an "account identifier 
for uniquely specifying a given account with an account balance and at least one item 
table identifier." See , e.g., Carlisle, Col. 2, lines 24-26. 

Thus, each account of each data file has a table listing items that such account 
can be used to purchase. Further, according to Carlisle, if an item identifier of an 
item presented at a POS terminal does not correspond to any of the items in the item 
table of each of the accounts A, B, . . ., n, the cost of the item is retrieved from the cost 
table and added to a residual account which includes the costs of all items having item 
identifiers obtained by the item identification device which do not correspond to any 
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of the items in the item table." See , e.g., Carlisle, Col. 2, lines 52-58. Thus, it is clear 
that each of the multiple applications shown in Fig. 1 1 of Carlisle et al. stores only 
application-specific value (i.e., a value for transaction of those particular items 
allowed and listed in an item table of each application). 

Further, it is clear that the electrical purse, residual account, savings account, 
or checking account of Carlisle store only application-specific value. With regard to 
the residual account, Carlisle clearly states, as mentioned above, that such account 
stores only value specific for the transaction of those particular items that are rejected 
by the accounts A, B, . . n of the multiple applications. See , e.g., Carlisle, Col. 19, 
lines 35-39 and 49-52 and Col. 20, lines 42-57. Thus, it is clear that the residual 
account stores only an application-specific value. With regard to the electronic purse, 
savings account, and checking account, those accounts are used as accounts A, B, . . 
n. See, e.g., Carlisle, Col. 13, lines 14-Col. 15, line 58; Col. 21, lines 50-56. 
Consequently, it is clear that the electronic purse, the saving account, and the 
checking account are all used to store only application-specific value for transaction 
of those particular items allowed and listed in an item table of each application. 
Accordingly, the multiple applications and their multiple accounts of Carlisle et al., 
be they Visa accounts, MasterCard accounts, electronic purses, residual accounts, 
savings accounts, checking accounts, etc., store only application-specific values, and 
not both application-specific and general values. 

Derksen and Gungl fail to remedy the deficiencies of Carlisle. On the 
contrary, Carlisle, Derksen and Gungl, either separately or in combination with one 
another, neither teach nor suggest storing both general value application-specific 
value on the smart card, as recited in claims 1,18, 27, 37, and 45. Derksen teaches a 
card storing different value limits in two or more "separate money compartments" 
which can each be used only at certain designated "payment sites" pursuant to certain 
"payment site arrangements." The "payment sites" include one to pay for services, 
including "public transport, tolls, and admission tickets," another that is likewise used 
for such payments and can also be reloaded, and still another that is also used for such 
payments, as well as "eating in certain restaurants" and can also establish on line 
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contact with a verification agency for authentication and correction or reloading the 
card from an account of the card holder or debiting the card holder's account. See , 
e.g., Derksen, Col. 2, lines 35-37; Col. 4, lines 25-31; Col. 6, lines 47-50; and Col. 7, 
lines 9-25. 

Consequently, it is likewise clear that the "separate money compartments" of 
Derksen which can be used only at certain designated "payment sites" pursuant to 
certain "payment site arrangements" are only application-specific value for 
transactions at only those certain designated "payment sites" pursuant to those certain 
"payment site arrangements". Accordingly, the "separate money compartments" of 
Derksen store only application-specific values and not general values, and it is also 
self-apparent that the "separate money compartments" of Derksen do not store both 
application-specific and general values. 

Further, Gungl, teaches away from storing both application-specific and 
general values on a transaction card, as recited in claims 1,18, 25, 37, and 45. 
Specifically, Gungl, teaches a chip card whereby "application programs which are 
stored on the chip card do not have access to each other." See , e.g. Gungl, Col. 3, 
lines 20-22 (emphasis added). Although there is language in Gungl about 
"communication" that may occur between independent units on a chip "when 
required" via a "control unit" ( See, e.g. Gungl, Col. 3, lines 35-44), there is no 
suggestion in Gungl that application-specific value and general value are being 
exchanged. There is also language in the Background section of Gungl at Col. 2, 
lines 26-56 about prior art chip cards known as "multifunction or multifunctional chip 
cards," that are susceptible to an operator of an application program because he may 
"move feely" on the chip card. Neither does this language in Gungl teach or suggest 
storing both an application-specific value and a general value on a transaction card, as 
recited in claims 1, 18, 25, 37, and 45. 

Electronic Payment Systems fails to remedy the deficiencies of Carlisle, 
Derksen, and Gungl. On the contrary, Carlisle, Derksen, Gungl, and Electronic 
Payment Systems, either separately or in combination with one another, neither teach 
nor suggest storing both general value application-specific value on the smart card 
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which are each exchangeable with one another in a transaction, as recited in claims 1 , 
18, 27, 37, and 45. Section 7.2.8 of Electronic Payment Systems, relied on by the 
Examiner, recites: 

Another proposed extension is to allow customers to convert unspent 
tickets back to real money. This would be done by sending the ticket to 
the vendor, who would pay the remaining account balance to the user 
using an existing macropayment system. A system in which any user 
can accept payments, such as an electronic cash system will have to be 
used for this purpose. Credit card systems cannot do this. The cost of 
the macropayment transaction may have to be covered by the merchant 
charging a fee for the service. 

It is noted that the context of the particular section of Electronic Payment 
Systems relates to "a simple micropayment protocol designed for efficient pay-per- 
view payments on the Internet" that "works by creating temporary prepaid accounts 
for users at a specific vendor." See , e.g., Electronic Payment Systems, Section 7.2. 
Further, an "unspent ticket" referred to in Section 7.2.8 of Electronic Payment 
Systems is simply "a special account identifier used to authenticate the account owner 
to the account maintained at the vendor site in order to make a micropayment 
purchase" that "is valid only at one particular merchant." 

Electronic Payment Systems likewise teaches away from storing both general 
value and application-specific value on the smart card which are each exchangeable 
with one another in a transaction, as recited in claims 1,18, 27, 37, and 45, in that the 
"unspent ticket" is only application-specific value prepaid to an online merchant that 
"is valid only at one particular merchant." Moreover, refund of the unspent balance 
of the prepaid value by the merchant to the account owner in "[a] system in which any 
user can accept payments, such as an electronic cost system" which "[c]redit cards 
cannot do" has absolutely nothing to do with storing both general value application- 
specific value on the smart card which are each exchangeable with one another in a 
transaction, as recited in claims 1,18, 27, 37, and 45. 

Consequently, Carlisle, Derksen, Gungl, and Electronic Payment Systems, 
either alone or in combination with one another, do not disclose, nor even suggest, at 
least the required combinations of limitations proposing that both application-specific 
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value and general value are stored on the transaction card and that the application- 
specific value and general value are each exchangeable with one another in a 
transaction, as recited in claims 1,18, 25, 37, and 45. Nor do Carlisle, Derksen, 
Gungl, and Electronic Payment Systems, either alone or in combination with one 
another, disclose or suggest, at least the required combinations of limitations 
proposing that both application-specific value and general value are stored on the 
transaction card and that each is compatible within the system for performing a 
transaction, as recited in claims 1,18, 37, and 45. 

Because the cited references, either alone or in combination, do not teach the 
limitations of independent claims 1,18, 25, 37, and 45, the Examiner has failed to 
establish the required prima facie case of unpatentability. See In re Royka , 490 F.2d 
981, 985 (C.C.P.A., 1974) (holding that a prima facie case of obviousness requires 
the references to teach all of the limitations of the rejected claim); See also MPEP 
§2143.03. Similarly, the Examiner has failed to establish a prima facie case of 
unpatentability for claims 3-16 that depend on claim 1, claims 19-24 that depend on 
claim 18, claims 26-36 that depend on claim 25, claims 38-44 that depend on claim 
37, and/or claims 46-48 that depend on claim 45, and which recite further specific 
elements that have no reasonable correspondence to the references. 

Rejection of Claims 36 and 43 under 35 U.S.C. § 103(a) 

Claims 36 and 43 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Carlisle et al. (U.S. 5,649,1 18), in view of (Derksen (U.S. 5,478,993) and Gungl 
et al. (U.S. Pat. No. 5,912,453)), in further view of Electronic Payment Systems as 
applied to the claims above, and further in view of Taskett (U.S. 5,991,748). 

The Examiner incorporated arguments found in the Final Office Action dated 
November 4, 2003. In view of the § 112 remarks presented above, the principal 
arguments presented in the Appeal Brief dated October 4, 2004 continue to be 
applicable and are presented below. 

As noted above, because Carlisle, Derksen, Gungl, and Electronic Payment 
Systems, either alone or in combination, do not teach the limitations of independent 
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claims 25 and 37, the Examiner has failed to establish the required prima facie case of 
unpatentability of independent claims 25 and 37, and similarly has failed to establish 
a prima facie case of unpatentability for claim 36 that depends on claim 1 and claim 
43 that depends on claim 37, and which recite further specific elements that have no 
reasonable correspondence to the references. 

Claim 36 depending on independent claim 25 proposes that, in addition to 
storing both the application-specific value and the general value which are each 
exchangeable between each other in the financial transaction, all of the application- 
specific value is exchanged in a transaction, new application-specific value is 
automatically loaded, at least a portion of which is exchanged to complete the 
financial transaction. Claim 43 proposes that, in addition to storing both the 
application-specific value and the general value which are both compatible for use in 
a transaction and are each exchangeable between each other in the financial 
transaction, a predetermined amount of application-specific value is added to the 
smart card if a sufficient amount of the application-specific value does not exist 
which exchanging a transaction amount of value that is at least a portion of the 
application-specific value or the general value. 

Taskett does not remedy the deficiencies of Carlisle, Derksen, Gungl, and 
Electronic Payment Systems. On the contrary, Traskett teaches a prepaid phone card 
having application-specific value (specific for making phone calls) and a prepaid 
instrument, credit or debit card that can be transferred to the phone card to replenish 
its account balance. However, while funds from the prepaid instrument, credit or 
debit card may be exchangeable in the sense of transferring value in and out, the 
prepaid phone card with its application-specific value is not exchangeable because it 
can only receive and convert funds from the prepaid instrument, credit or debit card 
into value specific for the application of making phone calls, whereas it cannot 
convert the specific value for phone charges back into funds for the prepaid 
instrument, credit or debit card. 

Consequently, Carlisle, Derksen, Gungl, Electronic Payment Systems, and/or 
Traskett, either alone or in combination with one another, do not disclose, nor even 
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suggest the required combinations of limitations proposing that all of the application- 
specific value stored on the smart card and exchangeable with the general value also 
stored in the smart card is exchanged in a transaction, new application-specific value 
is automatically loaded, at least a portion of which is exchanged to complete the 
financial transaction, as recited in claim 36. Nor do Carlisle, Derksen, Gungl, 
Electronic Payment Systems, and/or Traskett, either alone or in combination with one 
another disclose or suggest the required combinations of limitations proposing that a 
predetermined amount of application-specific value is added to the smart card if a 
sufficient amount of the application-specific value does not exist when exchanging a 
transaction amount of value that is at least a portion of the application-specific value 
or the general value both stored on the smart card and exchangeable between each 
other in the financial transaction, as recited in claim 43. 

Because the cited references, either alone or in combination, do not teach the 
limitations of claims 36 or 43, the Examiner has failed to establish the required prima 
facie case of unpatentability. See In re Rovka , 490 F.2d 981, 985 (C.C.P.A., 1974) 
(holding that a prima facie case of obviousness requires the references to teach all of 
the limitations of the rejected claim); See also MPEP §2143.03. 
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CONCLUSION 



The undersigned representative respectfully submits that this application is in 
condition for allowance, and such disposition is earnestly solicited. If the Examiner 
believes that the prosecution might be advanced by discussing the application with the 
undersigned representative, in person or over the telephone, we welcome the 
opportunity to do so. In addition, if any additional fees are required in connection 
with the filing of this response, the Commissioner is hereby authorized to charge the 
same to Deposit Account No. 501458. 



Respectfully submitted, 



Date: bf * y IC/> 

KILPATRICK STOCKTON LLP 
607 14th Street, N.W., Suite 900 
Washington, D.C. 20005 
(202) 508-5800 





Registration No, 44,433 
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